Summary

Extracts the SEP-2663 Tasks feature out of ModelContextProtocol.Core into a new
bolt-on package, ModelContextProtocol.Extensions.Tasks, mirroring the existing
ModelContextProtocol.Extensions.Apps. Core is left with no compile-time knowledge of
Tasks: the extension references the main package and layers Tasks behavior in from the
side.

Unlike Apps -- which was purely additive metadata over existing public APIs -- Tasks was
woven into Core's request-dispatch pipeline (task-augmented tools/call, redirection of
server-initiated sampling/elicitation/roots, and transparent client polling). To make
a clean side bolt-on possible, Core gains a small set of generic, typed seams. There is no
InternalsVisibleTo; the extension consumes only public Core API.

All of the new Core extensibility seams are marked [Experimental] (MCPEXP002) -- they are
preview extensibility hooks whose shape is expected to evolve (see #1704). The moved Tasks
feature APIs are non-experimental, consistent with #1642.

New public Core API surface (the seams)

ResultOrAlternate<TResult> -- a typed "result or a server-chosen alternate" envelope

namespace ModelContextProtocol.Protocol;

[Experimental("MCPEXP002")]
public class ResultOrAlternate<TResult> where TResult : Result
{
    public ResultOrAlternate(TResult result);                 // the immediate/standard result

    // The alternate arm is created through the typed factory; the untyped constructor is
    // private, so the alternate value always stays paired with its own serializer metadata.
    public static ResultOrAlternate<TResult> FromAlternate<TAlternate>(
        TAlternate alternate, JsonTypeInfo<TAlternate> alternateTypeInfo) where TAlternate : Result;

    public bool IsAlternate { get; }
    public TResult? Result { get; }
    public Result? Alternate { get; }
    public JsonTypeInfo? AlternateTypeInfo { get; }

    public static implicit operator ResultOrAlternate<TResult>(TResult result);
}

A handler that normally returns TResult can instead return an alternate Result subtype
(e.g. the Tasks extension answering tools/call with a CreateTaskResult). The alternate
carries its own JsonTypeInfo, so Core can serialize it without compile-time knowledge of
the concrete type -- keeping the path Native-AOT friendly.

Typed tools/call alternate handler + filters

namespace ModelContextProtocol.Server;

public sealed class McpServerHandlers        // reached via McpServerOptions.Handlers
{
    [Experimental("MCPEXP002")]
    public McpRequestHandler<CallToolRequestParams, ResultOrAlternate<CallToolResult>>? CallToolWithAlternateHandler { get; set; }
}

public sealed class McpRequestFilters        // reached via McpServerOptions.Filters.Request
{
    [Experimental("MCPEXP002")]
    public IList<McpRequestFilter<CallToolRequestParams, ResultOrAlternate<CallToolResult>>> CallToolWithAlternateFilters { get; }
}

The extension installs an alternate-result filter that may return a CreateTaskResult (the
"run this tool call as a task" path) while the normal typed tools/call pipeline is
preserved. The alternate handler/filters are mutually exclusive with the normal
CallToolHandler/CallToolFilters; mixing the two styles is rejected at configuration time
with an actionable error (so, today, WithTasks() cannot be combined with
AddAuthorizationFilters() -- composing them is tracked by #1704). A returned alternate that
is an InputRequiredResult is normalized by Core's MRTR backcompat resolver exactly like a
thrown InputRequiredException, so MRTR keeps working for non-MRTR clients regardless of
which form a handler uses.

Generic custom request handlers (for tasks/* methods)

namespace ModelContextProtocol.Server;

[Experimental("MCPEXP002")]
public sealed class McpServerRequestHandler
{
    public required string Method { get; init; }
    public required Func<JsonRpcRequest, CancellationToken, ValueTask<JsonNode?>> Handler { get; init; }
}

public sealed class McpServerOptions
{
    [Experimental("MCPEXP002")]
    public IList<McpServerRequestHandler>? RequestHandlers { get; set; }
}

Lets an extension own arbitrary JSON-RPC methods (tasks/get, tasks/update, tasks/cancel)
with full control over request/response serialization. This registry is method-keyed and
generic, so an extension can add more of its own RPCs with no Core change.

Scoped redirection of server-initiated outgoing requests

namespace ModelContextProtocol.Server;

public abstract partial class McpServer
{
    [Experimental("MCPEXP002")]
    public IDisposable InterceptOutgoingRequests(
        Func<string, JsonNode?, CancellationToken, ValueTask<JsonNode?>> interceptor);
}

While a tool runs as a task, its sampling/elicitation/roots requests must be captured
into the task store instead of sent to the client. InterceptOutgoingRequests installs an
interceptor and returns an IDisposable whose disposal restores the previous interceptor,
so the redirection lifetime is explicit and scoped.

Client input-request resolution hook

namespace ModelContextProtocol.Client;

public abstract partial class McpClient
{
    [Experimental("MCPEXP002")]
    public abstract ValueTask<IDictionary<string, InputResponse>> ResolveInputRequestsAsync(
        IDictionary<string, InputRequest> inputRequests, CancellationToken cancellationToken);
}

A public hook that lets the extension's client-side polling loop resolve server input
requests through the registered elicitation/sampling handlers.

Protocol-version gating reuses existing public surface (McpHttpHeaders.July2026ProtocolVersion /
IsJuly2026OrLaterProtocolVersion); no new draft-detection API is added to Core.

What moves to the extension

ModelContextProtocol.Extensions.Tasks owns all Tasks-specific surface:

• Protocol DTOs: CreateTaskResult (whose constructor sets the task result discriminator),
  GetTaskRequestParams/Result, UpdateTaskRequestParams/Result,
  CancelTaskRequestParams/Result, TaskStatusNotificationParams, McpTaskStatus,
  ResultOrCreatedTask<T>.
• Server: IMcpTaskStore, InMemoryMcpTaskStore, McpTaskExecutionContext, McpTaskInfo,
  InputResponseReceivedEventArgs.
• The task-augmented tools/call wrapper, the outgoing-request redirection, and the client
  polling loop -- all re-expressed on top of the Core seams above.
• tasks/* request methods, notifications/tasks/status, the task result discriminator,
  the RelatedTask meta key, the tasks extension capability string, and the Tasks
  [JsonSerializable] registrations.

Public entry points, mirroring Apps:

// server
builder.WithTasks(store);                                 // IMcpServerBuilder
server.CreateMcpTaskScope(taskId, store);                 // IDisposable
server.SendTaskStatusNotificationAsync(...);

// client
await client.CallToolWithPollingAsync(...);               // auto-polls to completion
ResultOrCreatedTask<CallToolResult> t = await client.CallToolAsTaskAsync(...); // manual lifecycle
await client.GetTaskAsync(id); await client.UpdateTaskAsync(...); await client.CancelTaskAsync(id);

Design rationale

• Strongly typed core path. ResultOrAlternate<TResult> and the typed
  CallToolWithAlternate* members keep the tools/call alternate path expressed in terms of
  real result types, and the envelope is a reusable, AOT-friendly primitive.
• Scoped redirection. Outgoing-request redirection is a scoped IDisposable
  (InterceptOutgoingRequests) that restores the previous interceptor on dispose.
• No InternalsVisibleTo. The extension depends only on public Core API, exactly like Apps.

Experimental surface

• The new Core extensibility seams -- ResultOrAlternate<T>, CallToolWithAlternateHandler,
  CallToolWithAlternateFilters, McpServerRequestHandler / McpServerOptions.RequestHandlers,
  McpServer.InterceptOutgoingRequests, and McpClient.ResolveInputRequestsAsync -- are all
  marked [Experimental] under the existing MCPEXP002 "Subclassing" (SDK-extensibility)
  diagnostic. They are preview extensibility hooks whose shape is expected to evolve; Make server extension handlers composable with filters and subscriptions #1704
  tracks generalizing the tools/call-specific alternate seam into a method-agnostic one.
• The moved Tasks feature APIs are non-experimental, consistent with Remove ExperimentalAttribute from official Extensions/Tasks/MRTR APIs and align MCPEXP001 usage #1642 (which removed
  [Experimental] from the official Tasks/MRTR feature APIs).

Breaking changes

This is a preview SDK and the change is intentionally breaking:

• Tasks public API moves out of ModelContextProtocol(.Core) into
  ModelContextProtocol.Extensions.Tasks; consumers add a package reference and a using.
• Task-store wiring and client task operations become extension methods
  (WithTasks(...), client.GetTaskAsync(...), etc.) rather than Core members.

Validation

• dotnet build clean (0 warnings / 0 errors) across net10.0/net9.0/net8.0/netstandard2.0
  with TreatWarningsAsErrors=true.
• Tasks and MRTR test suites pass across the target frameworks.